Key Objects¶

A key object is a collection of data for an asymmetric key, and is represented as keydata in this manual.

The exact contents of a key object are defined by the provider, and it is assumed that different operations in one and the same provider use the exact same structure to represent this collection of data, so that for example, a key object that has been created using the KEYMGMT interface that we document here can be passed as is to other provider operations, such as OP_signature_sign_init() (see provider-signature(7)).

With some of the KEYMGMT functions, it's possible to select a specific subset of data to handle, governed by the bits in a selection indicator. The bits are:

OSSL_KEYMGMT_SELECT_PRIVATE_KEY

Indicating that the private key data in a key object should be considered.

OSSL_KEYMGMT_SELECT_PUBLIC_KEY

Indicating that the public key data in a key object should be considered.

OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS

Indicating that the domain parameters in a key object should be considered.

OSSL_KEYMGMT_SELECT_OTHER_PARAMETERS

Indicating that other parameters in a key object should be considered.

Other parameters are key parameters that don't fit any other classification. In other words, this particular selector bit works as a last resort bit bucket selector.

Some selector bits have also been combined for easier use:

OSSL_KEYMGMT_SELECT_ALL_PARAMETERS

Indicating that all key object parameters should be considered, regardless of their more granular classification.

This is a combination of OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS and OSSL_KEYMGMT_SELECT_OTHER_PARAMETERS.

OSSL_KEYMGMT_SELECT_KEYPAIR

Indicating that both the whole key pair in a key object should be considered, i.e. the combination of public and private key.

This is a combination of OSSL_KEYMGMT_SELECT_PRIVATE_KEY and OSSL_KEYMGMT_SELECT_PUBLIC_KEY.

OSSL_KEYMGMT_SELECT_ALL

Indicating that everything in a key object should be considered.

The exact interpretation of those bits or how they combine is left to each function where you can specify a selector.

It's left to the provider implementation to decide what is reasonable to do with regards to received selector bits and how to do it. Among others, an implementation of OSSL_FUNC_keymgmt_match() might opt to not compare the private half if it has compared the public half, since a match of one half implies a match of the other half.

Constructing and Destructing Functions¶

OSSL_FUNC_keymgmt_new() should create a provider side key object. The provider context provctx is passed and may be incorporated in the key object, but that is not mandatory.

OSSL_FUNC_keymgmt_free() should free the passed keydata.

OSSL_FUNC_keymgmt_gen_init(), OSSL_FUNC_keymgmt_gen_set_template(), OSSL_FUNC_keymgmt_gen_set_params(), OSSL_FUNC_keymgmt_gen_settable_params(), OSSL_FUNC_keymgmt_gen() and OSSL_FUNC_keymgmt_gen_cleanup() work together as a more elaborate context based key object constructor.

OSSL_FUNC_keymgmt_gen_init() should create the key object generation context and initialize it with selections, which will determine what kind of contents the key object to be generated should get. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_keymgmt_set_params().

OSSL_FUNC_keymgmt_gen_set_template() should add template to the context genctx. The template is assumed to be a key object constructed with the same KEYMGMT, and from which content that the implementation chooses can be used as a template for the key object to be generated. Typically, the generation of a DSA or DH key would get the domain parameters from this template.

OSSL_FUNC_keymgmt_gen_set_params() should set additional parameters from params in the key object generation context genctx.

OSSL_FUNC_keymgmt_gen_settable_params() should return a constant array of descriptor OSSL_PARAM, for parameters that OSSL_FUNC_keymgmt_gen_set_params() can handle.

OSSL_FUNC_keymgmt_gen() should perform the key object generation itself, and return the result. The callback cb should be called at regular intervals with indications on how the key object generation progresses.

OSSL_FUNC_keymgmt_gen_cleanup() should clean up and free the key object generation context genctx

OSSL_FUNC_keymgmt_load() creates a provider side key object based on a reference object with a size of reference_sz bytes, that only the provider knows how to interpret, but that may come from other operations. Outside the provider, this reference is simply an array of bytes.

At least one of OSSL_FUNC_keymgmt_new(), OSSL_FUNC_keymgmt_gen() and OSSL_FUNC_keymgmt_load() are mandatory, as well as OSSL_FUNC_keymgmt_free() and OSSL_FUNC_keymgmt_has(). Additionally, if OSSL_FUNC_keymgmt_gen() is present, OSSL_FUNC_keymgmt_gen_init() and OSSL_FUNC_keymgmt_gen_cleanup() must be present as well.

Key Object Information Functions¶

OSSL_FUNC_keymgmt_get_params() should extract information data associated with the given keydata, see "Common Information Parameters".

OSSL_FUNC_keymgmt_gettable_params() should return a constant array of descriptor OSSL_PARAM, for parameters that OSSL_FUNC_keymgmt_get_params() can handle.

If OSSL_FUNC_keymgmt_gettable_params() is present, OSSL_FUNC_keymgmt_get_params() must also be present, and vice versa.

OSSL_FUNC_keymgmt_set_params() should update information data associated with the given keydata, see "Common Information Parameters".

OSSL_FUNC_keymgmt_settable_params() should return a constant array of descriptor OSSL_PARAM, for parameters that OSSL_FUNC_keymgmt_set_params() can handle.

If OSSL_FUNC_keymgmt_settable_params() is present, OSSL_FUNC_keymgmt_set_params() must also be present, and vice versa.

Key Object Checking Functions¶

OSSL_FUNC_keymgmt_query_operation_name() should return the name of the supported algorithm for the operation operation_id. This is similar to provider_query_operation() (see provider-base(7)), but only works as an advisory. If this function is not present, or returns NULL, the caller is free to assume that there's an algorithm from the same provider, of the same name as the one used to fetch the keymgmt and try to use that.

OSSL_FUNC_keymgmt_has() should check whether the given keydata contains the subsets of data indicated by the selector. A combination of several selector bits must consider all those subsets, not just one. An implementation is, however, free to consider an empty subset of data to still be a valid subset. For algorithms where some selection is not meaningful such as OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS for RSA keys the function should just return 1 as the selected subset is not really missing in the key.

OSSL_FUNC_keymgmt_validate() should check if the keydata contains valid data subsets indicated by selection. Some combined selections of data subsets may cause validation of the combined data. For example, the combination of OSSL_KEYMGMT_SELECT_PRIVATE_KEY and OSSL_KEYMGMT_SELECT_PUBLIC_KEY (or OSSL_KEYMGMT_SELECT_KEYPAIR for short) is expected to check that the pairwise consistency of keydata is valid. The checktype parameter controls what type of check is performed on the subset of data. Two types of check are defined: OSSL_KEYMGMT_VALIDATE_FULL_CHECK and OSSL_KEYMGMT_VALIDATE_QUICK_CHECK. The interpretation of how much checking is performed in a full check versus a quick check is key type specific. Some providers may have no distinction between a full check and a quick check. For algorithms where some selection is not meaningful such as OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS for RSA keys the function should just return 1 as there is nothing to validate for that selection.

OSSL_FUNC_keymgmt_match() should check if the data subset indicated by selection in keydata1 and keydata2 match. It is assumed that the caller has ensured that keydata1 and keydata2 are both owned by the implementation of this function.

Key Object Import, Export and Duplication Functions¶

OSSL_FUNC_keymgmt_import() should import data indicated by selection into keydata with values taken from the OSSL_PARAM array params.

OSSL_FUNC_keymgmt_export() should extract values indicated by selection from keydata, create an OSSL_PARAM array with them and call param_cb with that array as well as the given cbarg.

OSSL_FUNC_keymgmt_import_types() should return a constant array of descriptor OSSL_PARAM for data indicated by selection, for parameters that OSSL_FUNC_keymgmt_import() can handle.

OSSL_FUNC_keymgmt_export_types() should return a constant array of descriptor OSSL_PARAM for data indicated by selection, that the OSSL_FUNC_keymgmt_export() callback can expect to receive.

OSSL_FUNC_keymgmt_dup() should duplicate data subsets indicated by selection or the whole key data keydata_from and create a new provider side key object with the data.

Common Information Parameters¶

See OSSL_PARAM(3) for further details on the parameters structure.

Common information parameters currently recognised by all built-in keymgmt algorithms are as follows:

"bits" (OSSL_PKEY_PARAM_BITS) <integer>

The value should be the cryptographic length of the cryptosystem to which the key belongs, in bits. The definition of cryptographic length is specific to the key cryptosystem.

"max-size" (OSSL_PKEY_PARAM_MAX_SIZE) <integer>

The value should be the maximum size that a caller should allocate to safely store a signature (called sig in provider-signature(7)), the result of asymmmetric encryption / decryption (out in provider-asym_cipher(7), a derived secret (secret in provider-keyexch(7), and similar data).

Because an EVP_KEYMGMT method is always tightly bound to another method (signature, asymmetric cipher, key exchange, ...) and must be of the same provider, this number only needs to be synchronised with the dimensions handled in the rest of the same provider.

"security-bits" (OSSL_PKEY_PARAM_SECURITY_BITS) <integer>

The value should be the number of security bits of the given key. Bits of security is defined in SP800-57.